fix: backward compatability for did-update#92
Conversation
NullVoxPopuli
left a comment
NullVoxPopuli
left a comment
There was a problem hiding this comment.
Don't we want the original macro conditions?
const untrack = (function () {
if (macroCondition(dependencySatisfies('ember-source', '> 3.27.0-beta.1'))) {
// ember-source@3.27 shipped "real modules" by default, so we can just use
// importSync to get @glimmer/validator directly
return importSync('@glimmer/validator').untrack;
} else if (
macroCondition(dependencySatisfies('ember-source', '>= 3.22.0-alpha.1'))
) {
// we can access `window.Ember` here because it wasn't deprecated until at least 3.27
// eslint-disable-next-line no-undef
return Ember.__loader.require('@glimmer/validator').untrack;
} else {
// nothing needed here, we do not call `untrack` in this case
}
})();
|
yeah my thought was the same initially but I re-tested the original macro path and confirmed it still fails at runtime in the consumer (same DidUpdateModifier tracking assertion |
|
Can you try this PR? #93 |
|
I have a hunch this isn't needed -- I did some exploration in #93 and all scenarios pass without any macros. can you provide a reproduction of the issue you're experiencing? My hunch is that a build dep may be out of date. I'll close this for now , but let's please continue discussion on an issue |
2 participants
as part of modernization I broke compatibility layer on did-update, this adds it back in self contained way